Stream: Internet Engineering Task Force (IETF) 


RFC: 9090 

Category: Standards Track 
Published: July 2021 

ISSN: 2070-1721 
Author: C. Bormann 


Universitat Bremen TZI 


RFC 9090 
Concise Binary Object Representation (CBOR) Tags 
for Object Identifiers 


Abstract 


The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose 
design goals include the possibility of extremely small code size, fairly small message size, and 
extensibility without the need for version negotiation. 


This document defines CBOR tags for object identifiers (OIDs) and is the reference document for 
the IANA registration of the CBOR tags so defined. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9090. 


Copyright Notice 


Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
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with respect to this document. Code Components extracted from this document must include 
Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are 


provided without warranty as described in the Simplified BSD License. 
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1. Introduction 


The Concise Binary Object Representation (CBOR) [RFC8949] provides for the interchange of 
structured data without a requirement for a pre-agreed schema. [RFC8949] defines a basic set of 
data types, as well as a tagging mechanism that enables extending the set of data types supported 
via an IANA registry. 


This document defines CBOR tags for object identifiers (OIDs) [X.660], which many IETF protocols 
carry. The ASN.1 Basic Encoding Rules (BER) [X.690] specify binary encodings of both (absolute) 
object identifiers and relative object identifiers. The contents of these encodings (the "value" part 
of BER's type-length-value structure) can be carried in a CBOR byte string. This document defines 
two CBOR tags that cover the two kinds of ASN.1 object identifiers encoded in this way anda 
third one to enable a common optimization. The tags can also be applied to arrays and maps to 
efficiently tag all elements of an array or all keys of a map. This document is the reference 
document for the IANA registration of the tags so defined. 


1.1. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


The terminology of [RFC8949] applies; in particular, the term "byte" is used in its now-customary 
sense as a synonym for "octet". The verb "to tag (something)" is used to express the construction 
of a CBOR tag, with the object (something) as the tag content and a tag number indicated 
elsewhere in the sentence (for instance, in a "with" clause or by the shorthand "an NNN tag" for 
"a tag with tag number NNN"). The term "SDNV" (Self-Delimiting Numeric Value) is used as 
defined in [RFC6256], with the additional restriction detailed in Section 2.1 (no leading zeros). 


2. Object Identifiers 


The International Object Identifier tree [X.660] is a hierarchically managed space of identifiers, 
each of which is uniquely represented as a sequence of unsigned integer values [X.680]. (These 
integer values are called "primary integer values" in [X.660] because they can be accompanied by 
(not necessarily unambiguous) secondary identifiers. We ignore the latter and simply use the 
term "integer values" here, occasionally calling out their unsignedness. We also use the term 
"arc" when the focus is on the edge of the tree labeled by such an integer value, as well as in the 
sense of a "long arc", i.e., a (Sub)sequence of such integer values.) 


While these sequences can easily be represented in CBOR arrays of unsigned integers, a more 
compact representation can often be achieved by adopting the widely used representation of 
object identifiers defined in BER; this representation may also be more amenable to processing 
by other software that makes use of object identifiers. 
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BER represents the sequence of unsigned integers by concatenating self-delimiting 
representations [RFC6256] of each of the integer values in sequence. 


ASN.1 distinguishes absolute object identifiers (ASN.1 type OBJECT IDENTIFIER), which begin at 
a root arc ([X.660], Clause 3.5.21), from relative object identifiers (ASN.1 type RELATIVE-OID), 
which begin relative to some object identifier known from context ([X.680], Clause 3.8.63). As a 
special optimization, BER combines the first two integers in an absolute object identifier into one 
numeric identifier by making use of the property of the hierarchy that the first arc has only three 
integer values (0, 1, and 2) and the second arcs under 0 and 1 are limited to the integer values 
between 0 and 39. (The root arc joint-iso-itu-t(2) has no such limitations on its second arc.) 
If X and Y are the first two integer values, the single integer value actually encoded is computed 
as: 


X*40+Y 


The inverse transformation (again making use of the known ranges of X and Y) is applied when 
decoding the object identifier. 


Since the semantics of absolute and relative object identifiers differ and since it is very common 
for companies to use self-assigned numbers under the arc 1.3.6.1.4.1 (IANA Private Enterprise 
Number OID [IANA.enterprise-numbers]) that adds 5 fixed bytes to an encoded OID value, this 
specification defines three tags, collectively called the "OID tags" here: 


Tag number 111: Used to tag a byte string as the BER encoding [X.690] of an absolute object 
identifier (simply "object identifier" or "OID"). 


Tag number 110: Used to tag a byte string as the BER encoding [X.690] of a relative object 
identifier (also called "relative OID"). Since the encoding of each number is the same as for 
Self-Delimiting Numeric Values (SDNVs) [RFC6256], this tag can also be used for tagging a byte 
string that contains a sequence of zero or more SDNVs (or a more application-specific tag can 
be created for such an application). 


Tag number 112: Structurally like tag 110 but understood to be relative to 1.3.6.1.4.1 (IANA 
Private Enterprise Number OID [IANA.enterprise-numbers]). Hence, the semantics of the 
result are that of an absolute object identifier. 


2.1. Requirements on the Byte String Being Tagged 


To form a valid tag, a byte string tagged with 111, 110, or 112 MUST be syntactically valid contents 
(the value part) for a BER representation of an object identifier (see Table 1): 


Tag number Section of [X.690] 
111 8.19 


110 8.20 
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Tag number Section of [X.690] 


112 8.20 


Table 1: Tag Number and Section of X.690 
Governing Tag Content 


This is a concatenation of zero or more SDNV values, where each SDNV value is a sequence of 
one or more bytes that all have their most significant bit set, except for the last byte, where it is 
unset. Also, the first byte of each SDNV cannot be a leading zero in SDNV's base-128 arithmetic, so 
it cannot take the value 0x80 (bullet (c) in Section 8.1.2.4.2 of [X.690]). 


In other words: 


e The byte string's first byte, and any byte that follows a byte that has the most significant bit 
unset, MUST NOT be 0x80 (this requirement requires expressing the integer values in their 
shortest form, with no leading zeroes). 


e The byte string's last byte MUST NOT have the most significant bit set (this requirement 
excludes an incomplete final integer value). 


If either of these invalid conditions are encountered, the tag is invalid. 


[X.680] restricts RELATIVE-OID values to having at least one arc, i.e., their encoding would have 
at least one SDNV. This specification permits empty relative object identifiers; they may still be 
excluded by application semantics. 


To facilitate the search for specific object ID values, it is RECOMMENDED that definite length 
encoding (see Section 3.2.3 of [RFC8949]) be used for the byte strings that are used as tag content 
for these tags. 


The valid set of byte strings can also be expressed using regular expressions on bytes, using no 
specific notation but resembling Perl Compatible Regular Expressions [PCRE]. Unlike typical 
regular expressions that operate on character sequences, the following regular expressions take 
bytes as their domain, so they can be applied directly to CBOR byte strings. 


For byte strings with tag 111: 
/*(([\x81-\xFF ] [\x80-\xFF] *) ?[ \x@Q-\x7F])+$/ 

For byte strings with tags 110 or 112: 
/*(([\x81-\xFF] [\x80-\xFF] *) ?[\x@0-\x7F])*$/ 


A tag with tagged content that does not conform to the applicable regular expression is invalid. 
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2.2. Preferred Serialization Considerations 


For an absolute OID with a prefix of 1.3.6.1.4.1, representations with both the 111 and 112 
tags are applicable, where the representation with 112 will be five bytes shorter (by leaving out 
the prefix h'2b06010401' from the enclosed byte string). This specification makes that shorter 
representation the preferred serialization (see Sections 3.4 and 4.1 of [RFC8949]). Note that this 
also implies that the Core Deterministic Encoding Requirements (Section 4.2.1 of [RFC8949]) 
require the use of 112 tags instead of 111 tags wherever that is possible. 


2.3. Discussion 


Staying close to the way object identifiers are encoded in ASN.1 BER makes back-and-forth 
translation easy; otherwise, we would choose a more efficient encoding. Object identifiers in IETF 
protocols are serialized in dotted decimal form or BER form, so there is an advantage in not 
inventing a third form. Also, expectations of the cost of encoding object identifiers are based on 
BER; using a different encoding might not be aligned with these expectations. If additional 
information about an OID is desired, lookup services such as the OID Resolution Service (ORS) 
[X.672] and the OID Repository [OID-INFO] are available. 


3. Basic Examples 


This section gives simple examples of an absolute and a relative object identifier, represented via 
tag numbers 111 and 110, respectively. 


3.1. Encoding of the SHA-256 OID 
ASN.1 Value Notation: 
{ joint-iso-itu-t(2) country(16) us(84@) organization(1) gov(1@1) 


csor(3) nistalgorithm(4) hashalgs(2) sha256(1) } 


Dotted Decimal Notation: 2.16.840.1.101.3.4.2.1 


06 # UNIVERSAL TAG 6 
09 # 9 bytes, primitive 
60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 
# | SAG elie | A a2 eal show component encoding 
# 2.16 101 


Figure 1: SHA-256 OID in BER 
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D8 6F # tag(111) 
49 # 0b010_01001: mt 2, 9 bytes 
60 86 48 01 65 03 04 02 01 # X.698 Clause 8.19 


Figure 2: SHA-256 OID in CBOR 


3.2. Encoding of a MIB Relative OID 


Given some OID (e.g., lowpanMib, assumed to be 1.3.6.1.2.1.226 [RFC7388]), to which the 
following is added: 


ASN.1 Value Notation: 


{ lowpanObjects(1) lowpanStats(1) lowpanOutTransmits(29) } 


Dotted Decimal Notation: .1.1.29 


oD # UNIVERSAL TAG 13 
03 # 3 bytes, primitive 
01 01 1D # X.690 Clause 8.20 
# i ve) show component encoding 


Figure 3: MIB Relative Object Identifier in BER 


D8 6E # tag(110) 
43 # @b010_00011: mt 2 (bstr), 3 bytes 
01 01 1D # X.690 Clause 8.20 


Figure 4: MIB Relative Object Identifier in CBOR 


This relative OID saves seven bytes compared to the full OID encoding. 


4. Tag Factoring with Arrays and Maps 


The tag content of OID tags can be byte strings (as discussed above) but also CBOR arrays and 
maps. The idea in the latter case is that the tag construct is factored out from each individual 
item in the container; the tag is placed on the array or map instead. 


When the tag content of an OID tag is an array, this means that the respective tag is imputed to 
all elements of the array that are byte strings, arrays, or maps. (There is no effect on other 
elements, including text strings or tags.) For example, when the tag content of a 111 tag is an 
array, every array element that is a byte string is an OID, and every element that is an array or 
map is, in turn, treated as discussed here. 
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When the tag content of an OID tag is a map, this means that a tag with the same tag number is 
imputed to all keys in the map that are byte strings, arrays, or maps; again, there is no effect on 
keys of other major types. Note that there is also no effect on the values in the map. 


As a result of these rules, tag factoring in nested arrays and maps is supported. For example, a 3- 
dimensional array of OIDs can be composed by using a single 111 tag containing an array of 
arrays of arrays of byte strings. All such byte strings are then considered OIDs. 


4.1. Preferred Serialization Considerations 


Where tag factoring with tag number 111 is used, some OIDs enclosed in the tag may be encoded 
in a shorter way by using tag number 112 instead of encoding an unadorned byte string. This 
remains the preferred serialization (see also Section 2.2). However, this specification does not 
make the presence or absence of tag factoring a preferred serialization; application protocols can 
define where tag factoring is to be used or not (and will need to do so if they have deterministic 
encoding requirements). 


4.2. Tag Factoring Example: X.500 Distinguished Name 


Consider the X.500 distinguished name: 


Attribute Types Attribute Values 
c (2.5.4.6) US 

1 (2.5.4.7) Los Angeles 

s (2.5.4.8) CA 

postalCode (2.5.4.17) 90013 

street (2.5.4.9) 532 S Olive St 
businessCategory (2.5.4.15) Public Park 


buildingName (0.9.2342.19200300.100.1.48) Pershing Square 
Table 2: Example X.500 Distinguished Name 


Table 2 has four "relative distinguished names" (RDNs). The country (first) and street (third) 
RDNs are single valued. The second and fourth RDNs are multivalued. 


The equivalent representations in CBOR diagnostic notation (Section 8 of [RFC8949]) and CBOR 
are: 
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h' @992268993f22c640130': "Pershing Square" }]) 


Figure 5: Distinguished Name in CBOR Diagnostic Notation 


d8 6f 
84 
al 
43 
62 


a3 
43 
6b 


43 
62 


43 
65 


al 
43 
6e 


a2 
43 
6b 


4a 
6f 


550406 
5553 
550407 


4c6f7320416e67656c6573 
550408 


4341 
550411 


3930303133 

550409 
3533322053204f6c697665205374 
55040f 


5075626c6963205061726b 
8992268993f22c640130 


HHHHHHHHHHHHHHHHHHHHHH HH 


# 


tag(111) 
array(4) 

map (1) 
2.5.4.6 (4) 
text(2) 

"ygs" 

map (3) 
2.5.4.7 (4) 
text(11) 

"Los Angeles" 
2.5.4.8 (4) 
text(2) 

"CA" 

2.5.4.17 (4) 
text(5) 
"90013" 
map(1) 
2.5.4.9 (4) 
text(14) 

"532 S Olive St" 
map (2) 
2.5.4.15 (4) 
text(11) 
"Public Park" 


# @.9.2342.19200300.1080.1.48 (11) 


text(15) 


5065727368696e6720537175617265 # "Pershing Square" 


Figure 6: Distinguished Name in CBOR (109 Bytes) 


(This example encoding assumes that all attribute values are UTF-8 strings or can be represented 
as UTF-8 strings with no loss of information.) 


5. CDDL Control Operators 


Concise Data Definition Language (CDDL) specifications [RFC8610] may want to specify the use of 
SDNVs or SDNV sequences (as defined for the tag content for tag 110). This document introduces 
two new control operators that can be applied to a target value that is a byte string: 


e .sdnv, with a control type that contains unsigned integers. The byte string is specified to be 
encoded as an SDNV (BER encoding) [RFC6256] for the matching values of the control type. 
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e .sdnvseq, with a control type that contains arrays of unsigned integers. The byte string is 
specified to be encoded as a sequence of SDNVs (BER encoding) [RFC6256] that decodes to an 
array of unsigned integers matching the control type. 


e .oid, like .sdnvseq, except that the X*40+Y translation for absolute OIDs is included (see 
Figure 8). 


Figure 7 shows an example for the use of .sdnvseq for a part of a structure using OIDs that could 
be used in Figure 6; Figure 8 shows the same with the .oid operator. 


country-rdn = {country-oid => country-value} 
country-oid = bytes .sdnvseq [85, 4, 6] 
country-value = text .size 2 


Figure 7: Using .sdnvseq 


country-rdn 
country-oid 
country-value 


{country-oid => country-value} 
bytes .oid [2, 5, 4, 6] 
= text .size 2 


Figure 8: Using .oid 


Note that the control type need not be a literal; for example, bytes .oid [2, 5, 4, *uint] 
matches all OIDs inside OID arc 2.5.4, attributeType. 


6. CDDL Type Names 


For the use with CDDL, the type names defined in Figure 9 are recommended: 


oid = #6.111(bstr) 
roid = #6.110(bstr) 
pen = #6.112(bstr) 


Figure 9: Recommended Type Names for CDDL 


7. IANA Considerations 


7.1. CBOR Tags 


IANA has assigned the CBOR tag numbers in Table 3 in the 1+1 byte space (24..255) of the "CBOR 
Tags" registry [[ANA.cbor-tags], with this document as the specification reference. 
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Tag Data Item Semantics Reference 

111 byte string, array, object identifier (BER encoding) RFC 9090 
or map 

110 byte string, array, relative object identifier (BER encoding); SDNV RFC 9090 
or map [RFC6256] sequence 

112 byte string, array, object identifier (BER encoding), relative to RFC 9090 
or map 1.3.6.1.4.1 


Table 3: New Tag Numbers 


7.2. CDDL Control Operators 


IANA has assigned the CDDL control operators in Table 4 in the "CDDL Control Operators" 
registry [IANA.cddl], with this document as the specification reference. 


Name Reference 
.sdnv RFC 9090 
.sdnvseq RFC 9090 
oid RFC 9090 


Table 4: New CDDL Control Operators 


8. Security Considerations 
The security considerations of [RFC8949] apply. 


The encodings in Clauses 8.19 and 8.20 of [X.690] are quite compact and unambiguous but MUST 
be followed precisely to avoid security pitfalls. In particular, the requirements set out in Section 
2.1 of this document need to be followed; otherwise, an attacker may be able to subvert a 
checking process by submitting alternative representations that are later taken as the original (or 
even something else entirely) by another decoder that is intended to be protected by the 
checking process. 


OIDs and relative OIDs can always be treated as opaque byte strings. Actually understanding the 
structure that was used for generating them is not necessary, and, except for checking the 
structure requirements, it is strongly NOT RECOMMENDED to perform any processing of this kind 
(e.g., converting into dotted notation and back) unless absolutely necessary. If the OIDs are 
translated into other representations, the usual security considerations for non-trivial 
representation conversions apply; the integer values are unlimited in range. 
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An attacker might trick an application into using a byte string inside a tag-factored data item, 
where the byte string is not actually intended to fall under one of the tags defined here. This may 
cause the application to emit data with semantics different from what was intended. Applications 
therefore need to be restrictive with respect to what data items they apply tag factoring to. 
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